The service mode of the conventional URC is directly a point-to-point operation performed by the user by utilizing the original RC. The operation method is single and bothersome. Since these RCs have a variety of types of code-models, so in order to select a suitable type of RC, one must find a type of RC from the fussy specifications and then perform the complicated operation based on the specific operation requirements described in the specification. In this way, the service efficiency of the RC decreases to a large extent. Meanwhile, for the programmer and the user, the contents and the processes are fairly complicated, and it is easy to make mistakes. In the procedure of using it, the user may come into a condition that different brands and different types of RCs cannot be produced within the same RC kernel. In this way, in order to realize the function, the user should buy corresponding URC based on the requirement, thus increasing the economic burden of the user and to be bothersome.
Furthermore, as shown in FIG. 1, there is also a learning URC in the market, whose learning method is so called “code model match”. Such type of RC highly requires the resource configuration of the hardware and is restricted by the cost of the hardware, and the costs of the hardware also increase correspondingly. Furthermore, once an original RC is lost, the code values cannot be matched. The object for the user to buy a URC is that it can be used to replace the original RC in case the original one is lost. However, the range suitable for using such RC is limited, thus, it cannot be popularized.
Other URCs can control a certain type of electronic product, but it cannot control simultaneously a plurality of types of consumable electronic products, such as in a patent of U.S. Pat. No. 6,437,836 applied in U.S. Meanwhile, the operation method of such RC is complicated and cannot be learned and applied quickly by user.